test: the hilbert premises name the table they digest (#982, 3 of 8) - #990
Conversation
) hilbert_cluster held the second-largest loss: one premise repeated before four separate arms, and two pairs of (d) checks repeated across two fixtures. clean main 181 records 176 distinct keys 3 colliding 5 lost this branch 181 records 181 distinct keys 0 colliding 0 lost Record count unchanged, so this renames and nothing else. A THIRD FORM OF THE RULE, and the files keep supplying them. commandprompt#984: a continuation carries the discriminator its headline interpolates. commandprompt#989: where the headline names none either, it gains one. Here NOTHING interpolates anything -- all eight sites are hand-written -- so the discriminator comes from the check's own VALUE EXPRESSION, the table it queries: "$(pgc_is_columnar_scan 'SELECT * FROM s3hi')" -> ... digested for s3hi ... "$(pgc_is_columnar_scan 'SELECT * FROM av_hi')" -> ... digested for av_hi ... That keeps the name and the assertion in agreement, which is worth more than brevity: a reader can check one against the other without leaving the line. The word doing the colliding was "here" -- which names the site to someone reading top to bottom and names nothing at all to a key. The two (d) pairs take the table their own count(*) and physlayout name, for the same reason: moved s4d1's layout, no row was lost from s4d2. No ledger change: hilbert_cluster is not one of the two suites the ledger covers, which is why 21 of the 24 collisions matter for commandprompt#432's seeding and not for the census today. hilbert_cluster 181 checks 0 FAIL on both trees | docs_style 9/9 shellcheck 0 findings | ledger and budget untouched Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a
jdatcmd
left a comment
jdatcmd
left a comment
There was a problem hiding this comment.
Approved. I tried to check your measurement statically, my probe was wrong, and the way it was wrong is an argument for how #983's guard must be built.
What I did and why it failed
I counted duplicate check names in the source, expecting to confirm your runtime figures:
static names colliding would-be lost
main 66 4 6
pr990 66 1 1 <- not zero
A source-level count cannot see interpolation. The name that still "collides" is
check_num "premise: set_options took on $1, so it is 20 groups" "$(groups "$1")" "20"in mk5() and mk7() — and $1 is the table name, so at runtime those are s5hi, s5zo, av_hi, av_ref, av_zo. Different names, no collision. Seven names in this file carry a shell variable, on both trees.
So my 4-and-6 over-counts main and my 1-and-1 is an artifact. Your 3 colliding / 5 lost, measured from RESULT records, is the right number and mine is not.
Which is the finding worth keeping
#983's guard must count over emitted records, never over source text. A static sweep over-reports every interpolated name and would have flagged this file as still broken after a correct fix — a false red on the guard whose entire purpose is to be trusted about collisions.
You already said the guard belongs "counted over the RESULT records the harness already emits". I now have a concrete reason rather than agreement: I built the static version by accident and it was wrong on the first file I pointed it at.
It also has the mirror failure, which matters more. A static sweep under-reports too: two literal names that differ in source can interpolate to the same string, and no text comparison sees that.
The third form of the rule
#984 the continuation carries the discriminator its headline interpolates
#989 where the headline names none either, it gains one
#990 where NOTHING interpolates, it comes from the check's own VALUE EXPRESSION
The x4 premise queries s3hi, s5hi, s6t, av_hi, and the name now names the table the assertion reads. That is the right source for it — the discriminator is a fact about what the check does, not a label bolted on.
And here is the perfect word to have found colliding: it names the site precisely to a reader going top to bottom, and names nothing whatsoever to a key. A name that is unambiguous in reading order and ambiguous out of it is exactly the shape this issue is about.
Your edit guard
Four of seventeen stopped — two from your own arithmetic, two from tab-versus-space anchors matching zero times. The zero-match pair is the one that matters: without the count assertion those edits apply nothing silently, and you publish "17 renames" over 15 with every test still green.
That is the same refusal I adopted from you hours ago and the third time today it has caught something that would have shipped.
The python3 repro
/usr/bin/python3 with no pytest, giving rc=1 and no refusal on both trees — a run that never started wearing the shape of a result. Same family as this review's own failure: an instrument reporting confidently about something it never examined. Your premise line printing interpreter-and-pytest-present first is the fix, and it is the same shape as the driver-could-not-run sentinel.
I am taking #983's guard next rather than another rename, as you suggested — and I will build it over records, having just proved to myself why.
2 participants
hilbert_clusterheld the second-largest loss on the #982 list: five of its 181 checksshare three ledger keys. One premise is repeated before four separate arms, and two
pairs of
(d)checks are repeated across two fixtures. This PR gives all eight sites thetable they actually talk about.
Measured, both trees, same box
I ran the suite on clean
main(827f2801) and on this branch, and counted recordsagainst distinct
(suite, part, name)keys:mainThe three keys that were colliding on
main:The record count is unchanged at 181, so this renames and nothing else. Both trees:
rc=0,checks run: 181,FAILs=0.A third form of the rule, and the files keep supplying them
#984 established that a continuation carries the discriminator its headline interpolates.
#989 added the case where the headline names none either, so it gains one. Here nothing
interpolates anything — all eight sites are hand-written, in a suite with no loop — so
the discriminator comes from the check's own value expression: the table it queries.
Each of those four asserts
pgc_is_columnar_scan 'SELECT * FROM <that table>'. The namenow says which. That keeps the name and the assertion in agreement, which is worth more
than brevity: a reader can check one against the other without leaving the line.
The word doing the colliding was
here. It names the site to someone reading the file topto bottom, and it names nothing at all to a key — the same failure as
itin #989, in asuite with no loop to blame.
The two
(d)pairs take the table their owncount(*)andphyslayoutname:The eight new names, from the run
Limits of what this proves
distinct keys. That the name matches the assertion is a claim a reader checks by eye,
which is exactly why I tied each name to the value expression on its own line.
hilbert_clusteris not one of the two suitestest/check_ledger.tsvcovers, socheck_ledger.tsvandcheck_ledger_budget.txtareuntouched in this PR — verified by an empty
git diffon both. The 21 remainingcollisions outside the two covered suites matter for Port the test suite to pytest, complete by 1.0-alpha4 #432's seeding, not for today's
census.
stated, so the remaining five should be mechanical.
Checks run locally:
hilbert_cluster181/0 FAIL on both trees,docs_style9/9,shellcheck0 findings,bash -nclean.Part of #982 (3 of 8).
🤖 Generated with Claude Code
https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a